home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4497 < prev    next >
Encoding:
Text File  |  1996-08-06  |  1.9 KB  |  56 lines
  1. Newsgroups: comp.lang.c++
  2. Path: iiasa.ac.at!marek
  3. From: marek@iiasa.ac.at (Marek  MAKOWSKI)
  4. Subject: delete[] and template questions
  5. Message-ID: <1996Jan30.165654.2033@iiasa.ac.at>
  6. Organization: IIASA, Laxenburg, Austria
  7. X-Newsreader: TIN [version 1.2 PL2]
  8. Date: Tue, 30 Jan 1996 16:56:54 GMT
  9.  
  10. I would like to ask for comments on three easy questions illustrated
  11. by the following piece of code:
  12.  
  13. template <class I, class T>
  14. void mVect<I,T>::resize(I new_size) {
  15.    T *old = v;
  16.    v = new T[new_size];        // T *v is a private member of mVect
  17.     int size_of_elem = sizeof(T);        // <--- question 3
  18.     //
  19.     // do something
  20.     //
  21.    delete[] old;        // <--- questions 1 & 2
  22. }
  23.  
  24. I have the following questions:
  25. 1. Is it absolutely robust and portable to delete[] old, even
  26.    if a previous call was for new_size == 0 (or if v was allocated
  27.     by the ctor for the size == 0) ?
  28. 2. Is it correct to assume that no destructor is called by this statement ?
  29. 3. Is there any risk involved in using sizeof(T) in this statement ?
  30.  
  31. I used to be sure that the answers are:
  32. 1. Yes
  33. 2. Yes
  34. 3. No
  35.  
  36. However, I have recently started to port an application developed
  37. with SunPro (previously ported to Borland and checked with the
  38. Bounds-Checker32).
  39. The Watcom code blows-up on the delete[] statement (if a previous
  40. call was for new_size == 0) and gives warnings whenever it sees the
  41. sizeof(T).
  42. Of course I should assume that I have somewhere a nasty bug that
  43. does not wake-up for Borland/Bounds-checher nor for SunPro.
  44. However, while waiting for the answer from Watcom on how to fix
  45. the installation problem of the debugger, I would like to clarify,
  46. if my answers to the above questions are correct.
  47.  
  48. Thanks in advance for your time.
  49.  
  50. Marek
  51. -- 
  52.                   Marek Makowski  | Email: marek@iiasa.ac.at
  53.          International Institute  | Phone: (+43-2236) 807.561
  54.     for Applied Systems Analysis  | Fax:   (+43-2236) 71.313
  55.        A-2361 Laxenburg, Austria  | Web: http://www.iiasa.ac.at
  56.